> >Well, I have heard from some people who understand this rat's nest >of race conditions that most, if not all, the holes can be closed if >your kernel has proper support - basically, you need the /dev/fd file >descriptor driver, and instead of simply exec()'ing the #! interpreter >with the file as input (which is subject to a race condition), you >launch the interpreter with a /dev/stdin already nailed down to the >original (dev,inode) pair, thus prohibiting substitution on the fly. > >That's another mechanism, it's reasonable, but it's not 100% backward >combatable... > However, even with it eliminating the race condition set uid shell scripts just have way too many other problems to be useful or safe. Unless the shell doesn't use IFS, PATH, etc when it's setuid, then any script that's run on something which uses the /dev/fd method can still be subverted in seconds. The fact is, is there is no real excuse for needing to make something setuid a shell script other than laziness and should be something that's just eliminated completely. The /dev/fd method is nice for other things as well, but this isn't a need we have for it. If the kernel see's #! it should just refuse to look at the setuid bits. If you need something setuid, write a program (and then let Joe Hacker have it and source for a day). James